IBD = similar to BDD except it is to specify the internal structure of a single block. It is static (structural) view of the system or one of its parts. Unlike BDD the IBD does not display blocks, but the usages of blocks. IBD shows how the block must be assembled to create a valid instance of the block, and how an instance of the block must be connected to external entities (reference properties) to create a valid instance of the system as a whole.

Other words, IBD shows valid configuration of the block (BDD). Often the IBD is created with the BDD.

  

Note that the IBD here is a “Flow Oriented View” representing the Communication and Data Handling subsystem. Note how everything identified in the BDD is represented in the IBD. The IBD provides much of the same information as the BDD but also shows the specific connections among the internal part properties (using connectors).

Each block of IBD has the same name format as in the BDD (<part name> : <type> [multiplicity]). The multiplicity could also be written on the top right corner of the block (instead in the name). Reference properties in a IBD have dashed border (eps).

If connecting two properties via standard ports, it is conveyed that the services at each one provides and requires services of the other via the standard ports.

 

Item Flows

Item flow types = representation of matter, energy or data between two structures, noted with a filled in triangular arrowhead. They must have each end of the connector connected to another structure or border. The arrowhead points the direction of the flow and the C label above it indicates the flow property type.

 

Nesting

Nesting of Parts and References

IBD allows for nesting within other properties. Notice in the next example, the IBD is a “Service Oriented View”. SysML imposes no limits on how deeply one can nest, though may be limited by canvas and readability of diagrams. To help with notations, there is dot notation (similar to referencing methods of objects). For example below the sensorPaload.x-axisSS represents that x=axisSS is a property under sensorPayload, and is blocked by named Star Sensor.

 

In this example, the Flight computers are nested within the C&DH block. The port from flight computers to EPS is done by first going to the border of the C&DH. From that border, connects to the EPS. On the other hand, the Star Sensors connect directly to the flight computers, jumping over the C&DH boundary. Though both are valid, this is based on design judgement. Using the outer border is similar principle as object-oriented design of encapsulation. Generally, one should follow the rules of encapsulation and use port connections at the boundaries of their parent block.